…#16439)

# Overview

Addresses a long-standing TODO to separate out the pipette movement
conflict and deck-placement conflict code since they are completely
exclusive of each other and don't need to be in the same file.

## Changelog

- moved all pipette movement conflict checking code to
`pipette_movement_conflict.py`

## Risk assessment

None. Refactor only

fixes RQA-3277

<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

<!--
Describe your PR at a high level. State acceptance criteria and how this
PR fits into other work. Link issues, PRs, and other relevant resources.
-->

I noticed that the label text next to the toggle button no longer
displays on the Magnetic Module step form. This PR aims to fix that and
update the form to better match the
[design](https://www.figma.com/design/WbkiUyU8VhtKz0JSuIFA45/Feature%3A-Protocol-Designer-Phase-1?node-id=5536-13337&node-type=canvas&t=F8BuTfbRtt7v67rR-0).

## Test Plan and Hands on Testing

<!--
Describe your testing of the PR. Emphasize testing not reflected in the
code. Attach protocols, logs, screenshots and any other assets that
support your testing.
-->
- Create an OT-2 protocol and add a magnetic module GEN1 or GEN2
- Go to the Protocol Steps tab and add a step for Magnet

## Changelog

<!--
List changes introduced by this PR considering future developers and the
end user. Give careful thought and clear documentation to breaking
changes.
-->
- Added an optional boolean `isLabel` prop in
`ToggleExpandStepFormField` to handle displaying label text next to the
toggle button when needed
- Changed `magnetAction.label `from "Magnet action" to "Magnet state" in
`form.json`
- Remove Box component with borderBottom in `ToolBox` to get rid of
double grey separation lines
- Used `getInitialDeckSetup` and `getModulesOnDeckByType` to get the
slot location info for displaying the icon

## Review requests

<!--
- What do you need from reviewers to feel confident this PR is ready to
merge?
- Ask questions.
-->

## Risk assessment

<!--
- Indicate the level of attention this PR needs.
- Provide context to guide reviewers.
- Discuss trade-offs, coupling, and side effects.
- Look for the possibility, even if you think it's small, that your
change may affect some other part of the system.
- For instance, changing return tip behavior may also change the
behavior of labware calibration.
- How do your unit tests and on hands on testing mitigate this PR's
risks and the risk of future regressions?
- Especially in high risk PRs, explain how you know your testing is
enough.
-->

---------

Co-authored-by: shiyaochen <[email protected]>

Works towards RSQ-161

When we want a well set relevant to a specific pipette's interaction with a specific labware, we use a helper, getWellSetForMultichannel. This works great, but it doesn't have the ability to return relevant wells given a nozzle layout. So for example, if the pipette has a nozzle layout of "column" on a 96 channel, and the well of interest is A2, all 96-wells are returned.

This PR adds support for all current nozzle layouts, which are generally utilized in the context of partial tip configs.

In nozzle configurations which do not naturally incorporate the entire row/column (this is only the 8-channel column config with <8 nozzles, currently), return thewellName and the number of relevant wells "lower" than that well name. Ex, if B1 is the wellName and the active nozzle count is 4, return B1-E1.

If less wells are available than the activeNozzleCount, return fewer wells.

…ads (#16397)

<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

Counts Gripper Actions with `opentrons_tough_pcr_auto_sealing_lid` and
increased tracking with Plate Reader

## Test Plan and Hands on Testing

Ran scripts and checked results

## Changelog

Added function to count number of times
opentrons_tough_pcr_auto_sealing_lid lid is picked up by gripper
Added functionality to record each byonoy plate read and specify read
type and wavelength
Error handling for google sheets interaction.

## Review requests

<!--
- What do you need from reviewers to feel confident this PR is ready to
merge?
- Ask questions.
-->

## Risk assessment

<!--
- Indicate the level of attention this PR needs.
- Provide context to guide reviewers.
- Discuss trade-offs, coupling, and side effects.
- Look for the possibility, even if you think it's small, that your
change may affect some other part of the system.
- For instance, changing return tip behavior may also change the
behavior of labware calibration.
- How do your unit tests and on hands on testing mitigate this PR's
risks and the risk of future regressions?
- Especially in high risk PRs, explain how you know your testing is
enough.
-->

# Overview

This PR introduces the first version of an Opentrons liquid class
schema. Single liquid class definitions will adhere to this schema and
be keyed by pipette and tip type.

Closes AUTH-832

## Test Plan and Hands on Testing

- Look through schema and ensure it adheres to our finalized liquid
class testing matrix. Any feedback on schema structure/style is
appreciated.
- Try out some test data in a JSON validator. I created a base fixture
that passes schema validation. We can modify that for testing.

## Changelog

- create liquid class schema v1
- add fixture

## Review requests

See test plan. Should we leave keys for `patternProperties` pipette and
tip type less restrictive strings? Perhaps any `safeString` rather than
following more stringent regex?

## Risk assessment

low

`PipetteState` and `TipState` were both storing the length of the pipette's currently-attached tip. I think that duplication was accidental. The `TipState` one was only used in one place, so this deletes that in favor of the `PipetteState` one.

…id seal labware (#16345)

Covers PLAT-356, PLAT-264, PLAT-540

Publicizes "opentrons_tough_pcr_auto_sealing_lid" labware. Implements multilabware stacks, new labware allowedRole "lid" for labware, alongside "lidOffsets" subcategory of the gripper offsets.

…anguage setting to app config (#16393)

adds a config app language value to desktop/ODD and initializes i18n
language to the stored app language config value. detects the user's
system language in desktop app-shell and transmits to renderer via
IPC/redux. adds a system language config value.

closes PLAT-504, PLAT-497

…hem in app (#16448)

fix PLAT-476, PLAT-477, PLAT-478, PLAT-479, PLAT-481, PLAT-484, PLAT-486

…th fixed trash (#16451)

* fix(components): fix disabled button style in PD

* feat(components): add two icons for PD

* fix(protocol-designer): remove # from version text

…r module. (#16453)

…lect pipette screen (#16464)

* fix(protocol-designer): remove opentrons phrase from checkboxes in select pipette screen

* refactor(protocol-designer): export metadata as a component

#16461)

#16465)

* fix(protocol-designer): fix snackbar display issue in select a pipette

…EditInstrumentsModal (#16438)

* fix(protocol-designer): fix pipette type button display condition in EditInstrumentsModal

#16467)

Closes RQA-3286

Adds "fixed trash" as a predefined drop tip location for OT-2s during drop tip wizard.

Closes EXEC-760

The loadPipette command is important for executing commands associated with a specific pipette, but it also resets internal state, which can leads to bugs like the ones in the linked ticket. If the pipette has been loaded earlier (ie, during error recovery, synonymous with fixit command flows), we should not load the pipette. We still load the pipette during maintenance runs (drop tip wizard when not in error recovery).

# Overview

Wrap second `ProtocolOverview` column once minimum page width is hit

Closes AUTH-716

…mponent (#16432)

* fix(protocol-designer): update Step part design and export it as a component

Closes RSQ-161

This PR adds partial tip support during Error Recovery flows, specifically for tip pick-up during overpressure error recovery. After talks with design, users will be unable to select wells themselves if using a partial tip layout, since this helps prevents unexpected pickups. There are some special-cased copy updates, too.

Closes EXEC-765

Adds an option for toggling error recovery. If ER mode is disabled, the run fails instead of entering recovery mode.

Closes RQA-3589

It's insufficient to check if a run entered error recovery as the sole condition for whether or not to run the post-run drop tip wizard, because it's possible for a run to proceed through error recovery then encounter a terminal error. In these spots, we must show drop tip wizard.

To fix, determine whether the run just entered error recovery (or not). If it didn't, do the tip detection logic.

…teId (#16859)

Co-authored-by: Jamey Huffnagle <[email protected]>

Closes RQA-3596

# Overview

Adds a docs page and publishes API Reference entries for the Absorbance
Plate Reader.

Addresses RTC-488, RTC-508.

## Test Plan and Hands on Testing


[Sandbox](http://sandbox.docs.opentrons.com/docs-plate-reader/v2/modules/absorbance_plate_reader.html)

## Changelog

- Adds a new page, Absorbance Plate Reader Module, under Hardware
Modules
- Links to new page from Hardware Modules landing page
- Adds Absorbance Plate Reader to Module Setup page
- Adds H3s for modules in API Reference for easier navigation
- Edits to `AbsorbanceReaderContext` docstrings in `module_contexts.py`
- Cleaned up malformed note syntax _for Thermocycler_ in
`module_contexts.py`
- Removed nitpick rule from `conf.py` now that `AbsorbanceReaderContext`
is published
- 🆕 Instruct authors not to detect CSV dialect when using plate reader
output as RTP.

## Review requests

- Check that all descriptions are true to how the plate reader behaves.
- Double check that my code simulates — I have done this once.
- Do we need more information in any area, especially for CSV files?
  - Should we provide a sample? If so, where to put it?
- ✅ Should we give more concrete guidance on parsing the CSV other than
"you know how to write code, yeah"?
- 🆕 Do we need to list the four `wavelengths` values that actually
function on a default HW config?

## Risk assessment

v low, docs only

Closes RQA-3608, RQA-3609, RQA-3611, RQA-3613, RQA-3610, RQA-3612, and RQA-3615

Closes RABR-671, RQA-3213, and RQA-3595

…to boot-up. (#16882)

…6875)

#16870 but for chore_release-8.2.0

…16884)

Closes RQA-3583

Currently, the app inspects an errorType on a failed drop tip command to determine whether to throw the special case "home the gantry" error modal. Recently, the error type changed for failed update estimator commands, so the special modal was broken. Instead of special-casing the errorType for failed estimator commands, let's just assume that any failed estimator command is caused by an unknown position error and pop the special modal.

Note that this also handles any error in the same manner with a "MustHomeError" errorType, too.

Closes RQA-3581

)

fix RQA-3482

# Overview

Known issue for downgrading below 8.2 with a plate reader attached.

## Test Plan and Hands on Testing

Check in next alpha.

## Changelog

Single bullet in API release notes.

## Review requests

- Does this capture the issue properly? Is there a related app-side
issue?
- Do we need to mention the problem of downgrading a robot _on the same
network_ as a plate reader?

## Risk assessment

nil

…recovery (#16893)

Closes RQA-3614

# Overview

Prettier (or whatever runs in our JS lint action) demands a newline
after a markdown header. OK.

## Test Plan and Hands on Testing

Pass automated tests plz.

## Changelog

`\n`

## Review requests

Forgive this shameful and time-wasting PR.

## Risk assessment

none

…id_auto_seal_lid to release (#16903)

Covers RABR-669
Adds compatibility between `biorad_96_wellplate_200ul_pcr` and `opentrons_tough_pcr_auto_sealing_lid` with stacking z offset

…al place (#16919)

Covers EXEC-1019
Ensure the plate reader values are truncated to the third decimal place after being read during a protocol.

Closes RQA-3642, RQA-3632, RQA-3627, and RQA-3629

Closes RABR-672

Closes RQA-3645

Recent gripper firmware changes add new degrees of G axis "home" state, and this ultimately causes the unsafe/ungripLabware command to fail, since a successful completion of the ungrip does not set the HOME flag. Because we ultimately want to ungrip the labware AND home the gripper G axis, let's use a parameterized home command instead.

* fix(components): fix unit text wrap-issue

…losed (#16941)

Covers RABR-674
Raises  an error during analysis when the plate reader lid is not closed and a read is attempted.

…#16954)

Closes RQA-3643

Because drop tip flows is no longer deterministic, we shouldn't show the progress bar and step counter.

…e recovery policies during a run (#16950)

Closes RQA-3670

We need to support the client ignoring several different classes of errors in a single run, which means the app needs to know the current recovery policy and be able to modify. This PR adds the necessary infrastructure to support that.

Co-authored-by: Max Marrone <[email protected]>

fix RQA-3570, RQA-3572, RQA-3573, RQA-3633, RQA-3634